home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0799 / 477 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  2.4 KB
  1. Date: Sun, 26 Jun 1994 17:54:34 -0400 (EDT)
  2. From: Timothy Miller <millert@undergrad.csee.usf.edu>
  3. Subject: Re: text marks & sliders
  4. To: gem-list@world.std.com
  5. In-Reply-To: <9406262108.AA14037@lip.ens-lyon.fr>
  6. Message-Id: <Pine.3.87.9406261734.A23976-0100000@grad>
  7. Mime-Version: 1.0
  8. Precedence: bulk
  9.  
  10. Hollis:
  11.  
  12. ) Sliders MUST be handled in a redraw-as-you-drag (or active-drawing)
  13. ) method in order to provide full functionality.  Any sliders that are
  14. ) designed to display information (such as scaling percentages, etc) should
  15. ) be displayed either within the slider bar, or to the direct right or
  16. ) left of the slider track.  Sliders that take time to draw information
  17. ) based on their position must be ghost-drag type.
  18.  
  19. Are there any standard library routines I could get for active-drawing?
  20.  
  21.  
  22. ) If the mouse is placed over an editable text field, the mouse MUST change
  23. ) to a TEXT CURSOR while the mouse is over it.  It must be changed back to
  24. ) its original form when moved away.
  25.  
  26. This isn't an easy thing to do.  It requires constant tracking of the 
  27. mouse position.  Do you have an easy way to do this?
  28.  
  29. All of this should have been built into the OS from day one, but it 
  30. wasn't, and I don't like the fact that on an Atari I have to implement 
  31. all this myself, while on a Mac or Windows, it's built into the OS.
  32.  
  33. Well, it's not biggie if someone publishes source code for a handler that 
  34. does all this, but if I can't compile it without modification, or I can't 
  35. read the code, I'm going to complain.  That's what I hate about getting 
  36. code that someone else wrote.  They never work the first time, and I 
  37. can't read them.
  38.  
  39. Come to think of it, I may write my own handler.  Would anyone object 
  40. terribly of my dialog system required it's own type of resource file?  
  41. This way, the resource editor could be WYSIWYG for all the various types 
  42. of extentions... in that case, we could have edit fields that use 
  43. proportionally spaced SpeedoGDOS fonts.  In that case, you'd use a normal 
  44. resource editor for most stuff, and mine for the extended-type dialogs.
  45.  
  46. Don't hold your breath on this, though, and others should work on similar 
  47. programs.... competition, you know.  I don't exactly have gobbs of free 
  48. time.  And if I write this thing, I will not obfuscate my code simply for 
  49. the sake of keeping ahead of my competitors, so there will have to be an 
  50. element of trust involved.
  51.  
  52. I just realized that I don't know how to build an object tree from 
  53. scratch.  Hmmm.
  54.  
  55.  
  56.  
  57.